\subsection{Überblick}

\noindent Die Sicherheitsziele der Applikation sind:

\begin{itemize}
    \item Datenintegrität
    \item Authentizität
    \item Nichtabstreitbarkeit
    \item Vertraulichkeit
    \item Verfügbarkeit
    \item Compliance
    \item Privacy
\end{itemize}

\noindent Im Folgenden werden diese Ziele näher beschrieben.

\subsection{Datenintegrität}

Die Daten, die bei der Kommunikation zwischen Modulen ausgetauscht sowie in den Datenbanken gespeichert werden, müssen vor unerlaubten Änderungen geschützt sein. Konkret darf es einem Angreifer etwa nicht möglich sein, Transaktionen hinzuzufügen oder bestehende Transaktionen zu ändern, um so Kontostände zu verändern. Die folgenden Bereiche sind von diesem Ziel betroffen:

\begin{itemize}
    \item Gespeicherte Kunden im \KM
    \item Gespeicherte Karten in der \KV
    \item Gespeicherte Transaktionen in der \TV
    \item Private und Public Keys, die zur Verschlüsselung und Signierung eingesetzt werden
    \item Übertragene Daten auf den Kommunikationskanälen zwischen den Modulen und zur Außenwelt
\end{itemize}

\noindent Mögliche Angriffe gegen dieses Ziel sind:

\begin{itemize}
    \item MITM-Attacken
    \item Replay-Attacken
    \item SQL-/Command-Injection
    \item Malware (Exploit, Buffer Overflow, ...)
    \item Insider-Attacken
\end{itemize}

\subsection{Authentizität}

Sämtliche Benutzer und Komponenten, die mit dem System zusammenarbeiten, müssen sich authentifizieren und entsprechend ihrer Rechte in ihrem Handeln eingeschränkt sein. Im Speziellen sind davon betroffen:

\begin{itemize}
    \item Authentifizierung von Kunden auf der Self-Management-Website über das \KM
    \item Authentifizierung von Mitarbeitern im Mitarbeiter-Backend über das \KM
    \item Authentifizierung von Kartenterminals gegenüber der \TV
    \item Authentifizierung von Kartenbesitzern gegenüber dem \Term
    \item Gegenseitige Authentifizierung der Module bei Nachrichtenübertragung
\end{itemize}

\noindent Außerdem muss sichergestellt sein, dass nur Module miteinander kommunizieren können, die dazu berechtigt sind.

\noindent Mögliche Angriffe gegen dieses Ziel sind:

\begin{itemize}
    \item Gefälschte Kreditkarten
    \item Spoofing-Attacken (gefälschte Terminals)
    \item MITM-Attacken
    \item Passwort-Attacken
    \item Phishing-Attacken
    \item Session Hijacking
    \item Insider-Attacken
\end{itemize}

\subsection{Nichtabstreitbarkeit}

Es muss im Nachhinein nachweisbar sein, dass Transaktionen tatsächlich zu einem gewissen Zeitpunkt stattgefunden haben und dass damals tatsächlich ein bestimmter Benutzer, eine bestimmte Karte und ein bestimmtes \Term{} an der Transaktion beteiligt waren.

Weiters muss nachvollziehbar sein, wann welche gespeicherten Datensätze von welchem Benutzer geändert wurden.

\subsection{Vertraulichkeit}

Die Daten, die bei der Kommunikation von Modulen ausgetauscht werden, müssen vor unerwünschten Lesern geschützt sein. Ebenso müssen sensible, gespeicherte Daten vor Fremdzugriff geschützt sein. Insbesondere betrifft das:

\begin{itemize}
    \item Gespeicherte Karteninformationen
    \item Gespeicherte Daten von Kunden
    \item Gespeicherte Transaktionen
    \item Private Keys, die zur Verschlüsselung und Signierung eingesetzt werden
    \item Auf Kommunikationskanälen übertragene Daten
    \item Versendete Nachrichten im \BS
\end{itemize}

\noindent Mögliche Angriffe gegen dieses Ziel sind:

\begin{itemize}
    \item Spoofing-Attacken
    \item MITM-Attacken
    \item Passwort-Attacken
    \item Phishing-Attacken
    \item Session Hijacking
    \item Insider-Attacken
    \item Social Engineering
\end{itemize}

\subsection{Verfügbarkeit}

Das Bezahlsystem muss eine hohe Verfügbarkeit aufweisen, um Kunden zu jeder Zeit eine Bezahlungsmöglichkeit zu geben. Stark davon betroffen sind:

\begin{itemize}
    \item \TV
    \item \KV
    \item Kommunikationskanäle zwischen \Term, \TV und \KV
\end{itemize}

\noindent Weniger stark davon betroffen sind:

\begin{itemize}
    \item \KM
    \item \BS
\end{itemize}

\noindent Die letztgenannten Bereiche können vereinzelte Ausfälle verkraften.

\noindent Mögliche Angriffe gegen dieses Ziel sind:

\begin{itemize}
    \item DDoS-Attacken (Smurf, Ping of death etc.)
\end{itemize}

\subsection{Compliance}

Die Systeme zur Abwicklung von Zahlungen und insbesondere zur Speicherung von sensiblen Daten müssen allen rechtlichen Grundlagen entsprechen. Gesetze, welche die Einzelheiten und Anforderungen dieser Prozesse regeln, müssen bei der Entwicklung berücksichtigt und stets eingehalten werden.

Ein Beispiel für solch eine rechtliche Regelung ist die Aufbewahrungspflicht von Kundendaten. Kunden- und Kreditkartendaten dürfen nicht sofort tatsächlich gelöscht, sondern zunächst nur als gesperrt bzw. ungültig markiert und erst nach 5 Jahren tatsächlich gelöscht werden. Diese Maßnahme ist notwendig um die rechtliche Aufbewahrungsfrist laut §18 des Zahlungsdienstgesetz (ZaDiG) in Österreich zu erfüllen. Nach diesen 5 Jahren ist die minimale gesetzliche Aufbewahrungsfrist abgelaufen, wodurch die Daten nicht mehr aus "`Gründen der Wirtschaftlichkeit"' benötigt werden und laut §27 des Datenschutzgesetzes (DSG) das Recht auf Löschung in Kraft tritt. Weil die zur Löschung markierten (gesperrten) Daten dann nicht mehr für den "`Zweck der Datenanwendung benötigt werden"' sind diese Daten laut §27 DSG (1)  zu löschen, da diese Daten sonst als "`unzulässig verarbeitet Daten"' laut DSG gelten und eine Weiterverwendung dieser Daten strafbar ist.
